home *** CD-ROM | disk | FTP | other *** search
/ Experimental BBS Explossion 3 / Experimental BBS Explossion III.iso / gus / sdkdigv8.zip / SDKV8N13.TXT < prev    next >
Text File  |  1994-01-16  |  10KB  |  221 lines
  1. Apparently-To: john.smith@gravis.com
  2.  
  3.  
  4. GUS Programmer's Digest     Sat, 15 Jan 94  3:59         Volume 8: Issue  13  
  5.  
  6. Today's Topics:
  7.                          Mod to 669 converter
  8.                            Patches in DOS.
  9.                        Specific GUS Patch probs
  10.                               subscribe
  11.                       Using Gusmod in my sources
  12.  
  13. Standard Info:
  14.     - Meta-info about the GUS can be found at the end of the Digest.
  15.     - Before you ask a question, please READ THE FAQ.
  16.  
  17. ----------------------------------------------------------------------
  18.  
  19. Date: Fri, 14 Jan 1994 16:54:00 -0500
  20. From: brian.mccarthy@canrem.com (Brian Mccarthy)
  21. Subject: Mod to 669 converter
  22.  
  23.  Does anyone have/seen a .MOD to .669 converter?
  24.  
  25. TTYL
  26.  
  27. ------------------------------
  28.  
  29. Date: Fri, 14 Jan 1994 12:48:50 +0100
  30. From: appel@stack.urc.tue.nl (Stanley Appel)
  31. Subject: Patches in DOS.
  32.  
  33. I saw someone complain about how and what with patches. I had/have
  34. the same problem and mailed it to forte (with some other bug/errors found
  35. in the new SDK). They said it was not there design but from gravis and
  36. gravis has to disclose this information. They (gravis) are all requests
  37. on a case-by-case and because there are some rights on the pathes they
  38. won't release all information to the public. Forte adviced me to contact
  39. gravis personally and look if they release the information to me in person.
  40.  
  41. And I just wanted some dum program what displays me what to do with all
  42. the stupid values like envelope and tremolo etc.
  43.  
  44. Hope his help.
  45.  
  46. Stanley:
  47.  
  48. ------------------------------
  49.  
  50. Date: Fri, 14 Jan 1994 21:21:10 -0600 (CST)
  51. From: Jason William Whiteman <jww9624@tamsun.tamu.edu>
  52. Subject: Specific GUS Patch probs
  53.  
  54. Forte, Gravis, and Gravis UltraSound Developers:
  55.  
  56.      I would like to point out some problems with the SDK and offer some
  57. possible solutions.  All problems were encountered developing a patch file
  58. loader/player targeted for the DOS platform.  No outside code to interface
  59. with the GUS was used and none of the SDK's code was modified for the
  60. project.
  61.      First, I encountered the problem of how to handle the envelopes
  62. correctly.  The concepts seem simple enough, but one can over analyze
  63. what the SDK is saying; in turn, incorrectly implementing patches.
  64. The problem was this: should I interpret the envelope arranged as :
  65.  
  66. [1]
  67.  
  68. Envelope_Offset[1] -- Envelope_Rate[1] --> (Env.)Offset[2] ... --> 0 (Offset)
  69.  
  70. or should I use:
  71.  
  72. [2]
  73.  
  74. 0 (Offset) -- Envelope_Rate[1] --> Envelope_Offset[1] -- Envelope_Rate[1] ...
  75.  
  76.         After reviewing PATCH.EXE from the 2.01 SDK, the graphical
  77. representation of the envelope confirmed that [2] (starting at a zero
  78. offset, ramping to offset 1 with rate 1, etc. ) was the correct 
  79. interpretation.
  80.         Suggestion: Tell the developer about these type of assumptions.
  81. If this is indeed how the envelope works it would not be difficult to
  82. point this "quirk" out.
  83.  
  84.         Secondly, I found myself questioning the entire meaning of the 
  85. Envelope_Offset variable.  At first I thought I could just use the 
  86. envelope data to increase the volume of the current voice (patch) by
  87. whatever the Envelope_Offset said at whatever rate Envelope_Rate said.
  88. However, if this method is used, the patch will never fade (decay) to
  89. a zero volume level.  Using ACPIANO.PAT as a test patch, I noticed that
  90. apparent zero offsets (displayed with PATCH.EXE's graphical envelope)
  91. were actually set to an offset of "8".  After seeing this I made the
  92. assumption that envelopes have some sort of threshold point to mark a
  93. decay (ramp to zero volume level).  Here is some pseudo code for the
  94. code made under this assumption (threshold=10):
  95.  
  96.   Base_Volume = Volume_before_envelope; /* Remains constant for all points */  
  97.   if Last_Ramp is done then begin
  98.     
  99.     /* Ramp starts at current volume or Base_Volume + Last_Envelope_Point */
  100.     Ramp_Start_Volume = Base_Volume + Last_Envelope_Point;  
  101.     if This_Envelope_Point>10 then 
  102.       Ramp_End_Point = Base_Volume + This_Envelope_Point;
  103.     else
  104.       Ramp_End_Point = 0;  /* Offset is below threshold, marking a decay */
  105.                            /* to a volume of zero                        */
  106.  
  107. The above code was my attempt to get reasonably close to the way every Forte
  108. developed GUS software worked.  I do not know if this is correct.  In fact,
  109. I am assuming it is wrong and would like to be notified of the correct way
  110. to handle decays.
  111.         Suggestion: None provided.  Still unsure about it, myself.
  112.  
  113.         Lastly, and most importantly, I found a questionable omission from
  114. the SDK code provided.  The problem is with the way the SDK handles 
  115. the Voice Start and Voice End within UltraPrimeVoice.  Summary: the SDK
  116. cannot pass fractional memory address information to the GF1.  Explained:
  117.         With the current SDK, there is no way to implement fractional
  118. loop points.  This is due to UltraPrimeVoice's handling of addresses 
  119. passed to it.  First the addresses are converted into a 20-bit address.
  120. Second, this address is converted into both a high and low part and fed 
  121. to the GF1.  Since the low part is what contains the fractional address
  122. information, I will concentrate on that.  The low part is first ANDed
  123. with hex 7F (which zeros the high 9 bytes) then shifts that value to the
  124. left by 9.  This shifting left by 9 skips past (zeros) bits 0-4 (5 unused
  125. bits) and bits 5-8 (4 fractional bits).
  126.         UltraPrimeVoice's "begin", "start", and "end" address variables
  127. (VBegin, VStart, and VEnd in the Pascal SDK) have very different
  128. functions than the GF1's internal address variables.  The UltraPrimeVoice
  129. address variables do not have any bits dedicated to the fractional
  130. address points.
  131.         UltraPrimeVoice is the lowest-level code available in the SDK
  132. for setting up patch loop points.  UltraPrimeVoice does not support 
  133. fractional loop points; therefore, the developer cannot implement 
  134. fractional loop points using the current SDK.
  135.         Suggestion: Either a) block off 4 bits in UltraPrimeVoice's
  136. "begin", "start", and "end" address variables (Pascal: VBegin, VStart, 
  137. VEnd) or b) add another function where the full 32 bits of the 
  138. Frequency Control Register are available to the developer. 
  139. Note: unless those 5 unused bits are going to be doing anything on the
  140. GF1 that we don't know about, solution (a) seems to be the best route.
  141. Also note: since the Pascal SDK has no source code to the library (TPU),
  142. Pascal users cannot simply modify the SDK.  A simple solution for one
  143. to offer for this problem would be: "Sounds like you know how the
  144. Frequency Control Register is mapped out.  Why don't you just patch
  145. the SDK yourself?"  This is all fine and dandy for "C" programmers.
  146. However, Turbo Pascal programmers do not have source code available to
  147. patch.  Furthermore, none of the lower-level routines are available for
  148. them to use in writing their own alternative looping routine.  Perhaps
  149. a third suggestion for Pascal SDK developers would be to make ALL
  150. structures and functions available from the outside.  This is done by
  151. including ALL procedure prototypes above the "IMPLEMENTATION", as well
  152. as all the "TYPE", "CONST", and global variables.
  153.  
  154.         That's it for now.  I would like to see as much advancement as
  155. possible with Gravis UltraSound patch development.  I may put my source
  156. code on epas for those waiting for some patch code to be dropped in 
  157. their laps.  The code is in Pascal.  For "C" developers the code may
  158. be useful as pseudo-code for patch implementation.
  159.  
  160. Jason Whiteman
  161. jww9624@tamsun.tamu.edu
  162.  
  163. ------------------------------
  164.  
  165. Date: Fri, 14 Jan 94 16:30:36 CST
  166. From: Chevnut@osuunx.ucc.okstate.edu
  167. Subject: subscribe
  168.  
  169. subscribe
  170.  
  171. ------------------------------
  172.  
  173. Date: Fri, 14 Jan 94 21:25:27 +0200
  174. From: tjakobs@mswe.dnet.ms.philips.nl (THEO_JAKOBS TEL.62667)
  175. Subject: Using Gusmod in my sources
  176.  
  177. Hi..
  178.  
  179. Since a week or two, i'm programming in assembler, and i must say i've 
  180. programmed more graphix stuff now then i did in three years in pascal..
  181. But, i want my 'demos' to have some sound, so i thought, why not use
  182. gusmod in my program.
  183. But when i saw the listing, i was a little scared...
  184. What do i need for loading, and playing a mod... I mean which code do i
  185. need from the files...
  186.  
  187. I also have another question... Will my code be faster if i put the computer
  188. in 386 protected mode... I'm using some 286/386 code..
  189.  
  190. By the way, to the programmers of motion, the update is still silent on my
  191. GUS...
  192.  
  193. Well, Happy gussing fellows....
  194.  
  195. Andre Jakobs
  196.   MicroBrain Technologies Inc.
  197.     The Netherlands
  198.  
  199. ------------------------------
  200.  
  201. End of GUS Programmer's Digest V8 #13
  202. *************************************
  203.  
  204. To post to tomorrow's digest:                    <gus-sdk@dsd.es.com>
  205. To (un)subscribe or get help:            <gus-sdk-request@dsd.es.com>
  206. To contact a human (last resort):          <gus-sdk-owner@dsd.es.com>
  207.  
  208. FTP sites:           archive.epas.utoronto.ca              /pub/pc/ultrasound
  209.                      wuarchive.wustl.edu            /systems/ibmpc/ultrasound
  210.                      archive.orst.edu                    /pub/packages/gravis
  211.                      theoris.rz.uni-konstanz.de                /pub/sound/gus
  212.                      nctuccca.edu.tw                           /PC/ultrasound
  213. FTP mail server:     mail-server@nike.rz.uni-konstanz.de
  214.  
  215. Hints:
  216.       - Get the FAQ from the FTP sites or the request server.
  217.       - Mail to <gus-sdk-request@dsd.es.com> for info about other GUS
  218.     related mailing lists (general use, musician's, etc.).
  219.  
  220.  
  221.